Systems and methods for optimal component composition in a stream processing system

ABSTRACT

A system and method are provided for optimizing component composition in a distributed stream-processing environment having a plurality of nodes capable of being associated with one or more of a plurality of stream processing components. The system includes an adaptive composition probing (ACP) module and a hierarchical state manager. The ACP module probes a subset of the plurality of stream processing components to determine the optimal component composition in response to a stream processing request. The hierarchical state manager manages local and global information for use by said ACP module in determining the optimal component composition.

GOVERNMENT LICENSE RIGHTS IN FEDERALLY SPONSORED RESEARCH AND DEVELOPMENT

This invention was made with Government support under Contract No.: TIA H98230-04-3-0001 awarded by the U S. Dept. of Defense. The Government has certain rights in this invention.

BACKGROUND

1. Technical Field

The description generally relates to stream processing and, more particularly, to systems and methods for optimal component composition in a stream processing system.

2. Description of the Related Art

Emerging applications such as trade surveillance for security fraud, network traffic monitoring for intrusion detection, sensor data analysis, audio/video surveillance, and value-added voice-over-IP services, call for sophisticated real-time processing on data streams. In these applications, data streams are continuously pushed to stream processing servers, where they are processed by self-contained stream processing elements called “components”. Each component provides an atomic stream processing function such as filtering, aggregation, and correlation. Since stream applications are inherently distributed, stream processing should operate in a distributed fashion. Moreover, distributed stream processing systems provide better scalability and availability for resource-intensive and quality-sensitive stream processing applications. Thus, a challenging problem is to optimally compose distributed stream processing components into dynamically required stream processing applications.

Component composition has been studied under different contexts, such as service composition and systems software composition. The work on service composition is described, e.g., in the following articles, all of which are included by reference herein in their entireties: Raman et al., “Load Balancing and Stability Issues in Algorithms for Service Composition”, Proc. of IEEE INFOCOM 2003, San Francisco, Calif., pp. 1477-1487, April 2003; Gu et al., “QoS-Assured Service Composition in Managed Service Overlay Networks”, Proc. of IEEE 23rd International Conference on Distributed Computing Systems (ICDCS 2003), Providence, R.I., 194-201, May 2003; and Gu et al., “SpiderNet: An Integrated Peer-to-Peer Service Composition Framework”, Proc. of IEEE International Symposium on High-Performance Distributed Computing (HPDC 2004), Honolulu, Hi., 110-119, June 2004. The work on systems software composition is described, e.g., in the following article which is included by reference herein in its entirety: Kohler et al., “The Click Modular Router”, ACM Transactions on Computer Systems, 18(3), pp. 263-297, August 2000. Disadvantageously, the previous work falls short in addressing the optimization requirements in component composition, which is especially important for stream processing systems.

Previous work on stream processing has addressed problems such as load shedding and load migration. Load shedding is described, e.g., in the following article which is incorporated by reference herein in its entirety: Tatbul et al., “Load Shedding in a Data Stream Manager”, Proc. of the 29^(th) International Conference on Very Large Data Bases (VLDB'03), Berlin, Germany, 309-320, September 2003. Further, load migration is described, e.g., in the following article which is incorporated by reference herein in its entirety: Balazinska et al., “Contract-based Load Management in Federated Distributed Systems”, Proc. of 1^(st) Symposium on Networked Systems Design and Implementation (NSDI), San Francisco, Calif., 197-210, March 2004. Disadvantageously, the previous work does not address the optimal component composition problem.

Given the current state of the prior art, it would be beneficial and highly advantageous to have a system and method for optimal component composition in distributed stream processing environments.

SUMMARY

The present invention is directed to systems and methods for optimal component composition in distributed stream processing environment.

According to an aspect of the present invention, there is provided a system for optimizing component composition in a distributed stream-processing environment having a plurality of nodes capable of being associated with one or more of a plurality of stream processing components. The system includes an adaptive composition probing (ACP) module and a hierarchical state manager. The ACP module probes a subset of the plurality of stream processing components to determine the optimal component composition in response to a stream processing request. The hierarchical state manager manages local and global information for use by said ACP module in determining the optimal component composition.

According to another aspect of the present invention, there is provided a method for optimizing component composition in a distributed stream-processing environment having a plurality of nodes capable of being associated with one or more of a plurality of stream processing components. An adaptive composition probing (ACP) is performed which probes a subset of the plurality of stream processing components to determine the optimal component composition in response to a stream processing request. Local and global information are managed for use by the performing step in determining the optimal component composition.

According to yet another aspect of the present invention, there is provided a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for optimizing component composition in a distributed stream-processing environment having a plurality of nodes capable of being associated with one or more of a plurality of stream processing components. An adaptive composition probing (ACP) is performed which probes a subset of the plurality of stream processing components to determine the optimal component composition in response to a stream processing request. Local and global information are managed for use by the performing step in determining the optimal component composition.

These and other objects, features and advantages will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS

The disclosure will provide details in the following description of preferred embodiments with reference to the following figures wherein:

FIG. 1A is a block diagram illustrating a distributed stream processing system 100;

FIG. 1B is a component graph 180 of the distributed stream processing system 100 of FIG. 1;

FIG. 1C is a function graph 190 for the distributed stream processing system 100 of FIG. 1;

FIG. 2, which is a diagram illustrating an adaptive composition probing 200;

FIG. 3 is a diagram illustrating pseudo-code 300 for the ACP protocol;

FIG. 4 is a diagram illustrating a congestion aggregation calculation 400;

FIG. 5A is a plot 510 illustrating composition performance (success rate) versus probing ratio under different request rates; and

FIG. 5B is a plot 550 illustrating composition performance (success rate) versus probing ratio under different QoS requirements.

DETAILED DESCRIPTION OF PREFFERED EMBODIMENTS

The present invention is directed to a system and method for optimal component composition in distributed stream processing environments.

In contrast to the prior art, the present invention provides an adaptive and real-time system and method that is capable of solving constrained optimization problem in component composition. Of course, given the teachings of the present invention provided herein, other applications therefore may also be employed with respect to the present invention while maintaining the scope of the present invention.

The present description illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope.

All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions.

Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (“DSP”) hardware, read-only memory (“ROM”) for storing software, random access memory (“RAM”), and non-volatile storage.

Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the implementer as more specifically understood from the context.

In the claims hereof, any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The invention as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

A description will now be given regarding a distributed stream processing environment.

FIG. 1A is a block diagram illustrating a distributed stream processing system 100. FIG. 1B is a component graph 180 of the distributed stream processing system 100 of FIG. 1. FIG. 1C is a function graph 190 for the distributed stream processing system 100 of FIG. 1.

In FIGS. 1A through 1C, various components (stream processing elements) are designated by the reference characters C_(i) disposed within a circle (where i is an integer), various functions of the various components are designated by the reference characters F_(i) disposed within a circle, a data stream is designated by a solid thick line which is generally indicated by the reference numeral 101, an overlay link is designated by a solid thin line (i.e., thin with respect to the thicker line used to designated a data stream) which is generally indicated by the reference numeral 104), and functional dependencies are designated by a dashed line which is generally indicated by the reference numeral 102.

The distributed stream processing system 100 includes a set 111 of stream processing server nodes (V_(i)), each of which can be one or more computers (and thus are hereinafter interchangeably referred to as “computer”, “node”, or “server”) 115. For failure resilience, distributed nodes 115 are connected using application-level overlay links (e_(i)) 104 into an overlay mesh. Each node 115 provides a few stream processing components {c₁, . . . , c_(k)}. Each component provides an atomic stream processing function (F_(i)) such as filtering, aggregation, correlation, and audio/video analysis. Due to the constraints of security, software licenses, and hardware requirements, it is not presumed that each node can provide all stream processing components. The component composition process is to select and connect currently deployed components into user-required stream processing applications. Components can be dynamically migrated among nodes. The component composition operates based on the current component placement.

Each component receives continuous data units (e.g., data tuples, audio samples, video frames, and so forth) via input queues 103 from its preceding components, as illustrated in FIG. 1B. Each component has well-defined interfaces describing its input requirements (e.g., data format, stream rate, and so forth) and output properties. Each component is associated with a QoS vector [q₁ ^(c) ^(i) , . . . , q_(m) ^(c) ^(i) ] describing the QoS values of the component such as processing time and loss rate. The component can drop data units when it is overloaded, as described by Tatbul et al., in “Load Shedding in a Data Stream Manager”, Proc. of the 29^(th) International Conference on Very Large Data Bases (VLDB'03), Berlin, Germany, pp. 309-320, September 2003. Moreover, each component is associated with a resource availability vector [ra₁ ^(c) ¹ , . . . , ra_(n) ^(c) ^(i) ] describing the current available resources (e.g., CPU, memory, and so forth) on the node providing c_(i). Similarly, a QoS vector [q₁ ^(e) ^(i) , . . . , q_(m) ^(e) ^(i) ] and bandwidth availability ba^(e) ^(i) are also associated with each overlay link (e_(i)) 104.

A description will now be given regarding a composite stream processing service.

Distributed components can be dynamically composed into composite stream processing services. Generally, composition topology can be a directed acyclic graph (DAG), as illustrated in FIG. 1B. A component graph (λ) may be used to represent a composed stream processing application. Although the input queue 103 can accommodate transient stream rate mismatch, the input/output rates of two adjacent components must be compatible to provide continuous processing of long-lived data streams. Such a compatibility check is based on the interface specifications of the components. The input/output rates of the components are controlled by resource allocation policies. The QoS of a composed stream processing application is the QoS aggregation among its constituent components and overlay links. Herein, it is presumed that QoS metrics are additive and minimum-optimal. Non-additive metrics (e.g., loss rate, and so forth) can be made additive and minimum-optimal using logarithm and inverse transformations. The connection between two adjacent components is called a virtual link (l_(i)), which includes a set of overlay links. The QoS of the virtual link q₁ ^(l) ^(i) , . . . , q_(m) ^(l) ^(i) is the QoS aggregation among its constituent overlay links and its bandwidth availability ba^(l) ^(i) is the bottleneck bandwidth among the overlay links. If two adjacent components are co-located on the same machine, the virtual link is considered to have 0 network delay and ∞ bandwidth availability.

A description will now be given regarding the problem of optimal component composition.

The problem of optimal component composition is to map a function graph into a component graph in the distributed stream processing system based on resource and QoS constraints and an optimization objective function. The function graph 190 illustrated FIG. 1C represents the stream processing function requirements of a user. Each node 177 in the function graph 190 denotes an atomic stream processing function such as aggregation, filtering, and correlation. Each function node 177 can be mapped to multiple candidate components on different processing nodes. The optimal component composition has two principle goals. First, the composed stream processing application should satisfy the function, QoS, and “resource requirements” (the latter also referred to as “resource needs”) of the user. Second, the stream processing application should be instantiated on least loaded nodes and virtual links for balanced load distribution. The residual end-system resources on the node providing c_(i) are defined using [rr₁ ^(c) ^(i) , . . . , rr_(n) ^(c) ^(i) ]. The residual bandwidth on the virtual link l_(i) is defined using rb^(l) ^(i) . The residual resources are the remaining resources after the required resources are subtracted from current available resources on the corresponding nodes and virtual links. Residual resources are used instead of currently available resources for accommodating component co-locations, as further described herein. The required end-system resources for the component c_(i) are defined using R^(c) ^(i) =[r_(l) ^(c) ^(i) , . . . , r_(n) ^(c) ^(i) ]. The bandwidth requirement for the virtual link l_(i) is denoted by ba^(l) ^(i) . The stream processing function provided by the component c_(i) is denoted by c_(i).f.

Thus, the optimal component composition problem can be formally defined as follows: Given a distributed stream processing system G=(V,E) where V denotes the set of |V| stream processing nodes (v_(i)) and E denotes the set of |E| overlay links (e_(i)). Given a stream processing request

ξ, Q^(req), R^(req)

 where ξ denotes the function graph, Q^(req) denotes the QoS requirements, and R^(req) denotes the resource requirements. The optimal components composition problem is to find the best component graph

=(C,L)⊂G, where C denotes the set of |C| stream processing components (c_(i)) and L denotes the set of |L| inter-component virtual links (l_(i)) such that

$\begin{matrix} {{\min\;\phi\;(\lambda)} = {{\sum\limits_{c_{i} \in \lambda}^{\;}{\sum\limits_{k = 1}^{n}\frac{r_{k^{c_{i}}}}{{rr}_{k^{c_{i}}} + r_{k^{c_{i}}}}}} + {\sum\limits_{l_{i} \in \lambda}\frac{b^{l_{i}}}{{rb}^{l_{i}} + b^{l_{i}}}}}} & (1) \end{matrix}$ subject to c _(i) .f=F _(i) ,∀F _(i) εξ,∃c _(i)ελ  (2) q _(i) ^(λ) ≦q _(i) ^(req),1≦i≦m  (3) rr _(k) ^(c) ^(i) ≦0,1≦k≦n,∀c _(i)ελ  (4) rb ^(l) ^(i) ≦0,∀l _(i)ελ  (5)

Generally speaking, the optimal component composition problem is a multi-constrained optimization problem, which optimizes a global system metric subject to a set of constraints. Herein, the optimization goal is to minimize the congestion aggregation metric φ(λ) defined by Equation 1 for balanced load distribution. The smaller the congestion aggregation metric is, the better load distribution the composition presents, since the stream processing application on the nodes and virtual links are instantiated with larger residual resources. The constraints include the function of the user, and QoS and resource constraints for the composed stream processing application. Equation 2 defines that the component graph λ should provide all stream processing functions specified in the function graph ξ. Equation 3 specifies that the QoS of the composed stream processing application q₁ ^(λ), . . . , q_(m) ^(λ) (e.g., processing time, loss rate) should satisfy the user QoS requirements[q₁ ^(req), . . . , q_(m) ^(req)]. Equation 4 and Equation 5 specify that user required system resources and bandwidth resource should be satisfied (i.e., residual resources should not be negatives).

A general description of the present invention will now be provided, following by more detailed descriptions of various aspects thereof.

Herein, an optimal component composition system and method are provided that use adaptive composition probing (ACP). ACP can efficiently discover a set of “good” candidate component compositions among which the best composition is selected. ACP addresses two key decision-making problems: (1) how many candidate components to probe; and (2) which candidate components to probe. To accommodate dynamic stream processing systems, ACP adaptively adjusts the probed component number to maintain target composition performance with minimal probing overhead. For scalability, ACP selects good candidate components to probe under the guidance of a coarse-grain global state.

A description will now be given regarding system Application Programming Interfaces (APIs).

The user can specify the stream processing request in terms of: (1) function requirements described by a function graph (ξ); (2) QoS requirements (Q^(req)); and (3) resource requirements (R^(req)). The function graph 190 illustrated in FIG. 1C defines a stream processing application template, which can be provided by the application developer. The function graph 190 includes a set of function nodes (F_(i)) 177 connected by dependency links 102. In contrast to conventional request-response middleware interface, stream processing middleware provides the following three session-oriented interfaces.

The first interface, namely Session ID=Find (ξ,Q^(req),R^(req)), invokes the optimal component composition algorithm to find the best component graph λ. If the composition is successful, then the middleware creates a session record with a session identifier (sessionId) for the user request. Otherwise, a null sessionId is returned to indicate composition failure.

The second interface, namely Process (sessionId, data streams), starts the continuous data stream processing using the composed component graph. The middleware can map the session identifier to the component graph composed by the previous step.

The third interface, namely Close (sessionId), tears down the stream processing session when the application finishes its task. The corresponding session information is deleted from the session table.

A description will now be given regarding an overview of adaptive composition probing (ACP).

The basic idea of the ACP approach is to use a number of probing messages, called probes, to dynamically discover a set of good candidate compositions among which the best composition is selected. The probing process concurrently examines different compositions and collects precise state information from good candidate components. For scalability, ACP avoids brute-force exhaustive probing by performing adaptive selective probing. ACP addresses two key decision-making problems in composition probing: (1) how many candidate components should be probed and (2) which candidate components should be probe.

Intuitively, the more candidate components that are probed, the better component composition can be discovered. However, the probing overhead also becomes larger when more candidate components are probed. A probing ratio α

(0,1] is introduced to define the percentage of the candidate components probed for each function. For example, if there are ten candidate components for the function F_(i) and the probing ratio α=0.3, then 0.3×10=3 candidate components can be probed. ACP adaptively adjusts the probing ratio based on the target composition performance and current system conditions, which are described further herein.

Next, it is to be decided which candidate components to probe for maximizing the probability of finding the best composition. A hierarchical state management scheme is described herein to assist ACP in optimal component composition. The hierarchical state management maintains precise local state at each node and a coarse-grain global state, which is described further herein. Hence, ACP can select good components to probe under the guidance of the coarse-grain global state and select optimal component composition based on precise states collected by the probes. The candidate component selection is described further herein.

A description will now be given regarding ACP protocol.

When a stream processing request is submitted, the request is redirected to a node that is closest to the client based on a predefined proximity metric (e.g., geographical location, and so forth). The selected node, called the deputy node 202 (see FIG. 2), initiates the ACP protocol to discover the optimal component composition. FIG. 3 is a diagram illustrating pseudo-code 300 for the ACP protocol. Four steps are shown in FIG. 3. Each of these steps will now be described.

Regarding step 1 (initialization) in FIG. 3, given the component composition request, the deputy node 202 first selects a proper probing ratio for the request, which is further described herein below. The probing ratio decides the number of candidate components that are to be probed for each required function. Next, the deputy node creates a probing message (P₀) that carries the composition request information (e.g., the function graph ξ, QoS constraints Q^(req), resource constraints R^(req), and so forth), and the probing ratio α. The ACP protocol then enters the next step: distributed hop-by-hop probe processing. The probes will visit a number of selected candidate components to collect precise QoS/resource states.

Regarding step 2 (per-hop probe processing) in FIG. 3, when a node v_(i) receives a probe P_(i), the node processes the probe independently based on the information carried by the probe, the local state, and the coarse-grain global state 222 (it is to be noted that this step also applies to the deputy node). First, v_(i) checks whether or not the QoS/resource values of the probed partial stream processing application already violate the required QoS/resource values. If the QoS/resource values are already unqualified, then the probe is dropped immediately to reduce the probing overhead. Otherwise, the node performs transient resource allocation to avoid conflicting resource admission caused by concurrent probings for different requests. To avoid redundant resource allocation, each node only temporarily reserves resources once for each component in each request. The transient resource allocation will be cancelled after a timeout period if the node does not receive a confirmation message. Second, v_(i) derives the next-hop functions using the function graph ξ. The functions dependent on the current function are the next-hop functions. Third, v_(i) acquires the locations of all available candidate components for each next-hop function using a decentralized service discovery system. For a description of a decentralized service discovery system, see Gu et al., “SpiderNet: An Integrated Peer-to-Peer Service Composition Framework”, Proc. of IEEE International Symposium on High-Performance Distributed Computing (HPDC 2004), Honolulu, Hi., 110-119, June 2004. Fourth, v_(i) selects a number of “good” candidate components to probe, based on the probing ratio and the global state. The candidate component selection is further described herein below. Fifth, v_(i) “spawns” new probes from P_(i) for all selected next-hop candidate components. Each new probe 201 collects fine-grain local states from v_(i) and inherits the states collected by its parent probe. Finally, v_(i) sends all new probes 201 to the selected next-hop components.

Regarding step 3 (optimal composition selection) in FIG. 3, all the probes 201 belonging to a composition request will return to the initial deputy node 202. First, if the function graph is a DAG, then the deputy node 202 derives complete component graphs by merging the probed component paths. For example, in FIG. 2, which is a diagram illustrating an adaptive composition probing 200, a probe 201 can traverse c₁₀→c₂₀→c₄₀→c₆₀ or c₁₀→c₃₀→c₅₀→c₆₀. These two component paths can be merged into a complete component graph. Second, the deputy node 202 calculates the residual resources and accumulated QoS values for the candidate component graphs based on the precise state information collected by the probes. Third, the deputy node 202 selects qualified component compositions according to the constraints specified by Equations 2-5. Fourth, the deputy node 202 selects the optimal component composition from all the qualified ones according to the congestion aggregation metric φ(λ) defined by Equation 1. For example, in FIG. 4, which is a diagram illustrating a congestion aggregation calculation 400, the residual resource aggregation for the candidate component composition is calculated as:

${\phi\;(\lambda)} = {{\frac{20}{20 + 20} + \frac{10}{20 + 10} + \frac{40}{20 + 40} + \frac{200}{\infty + 200} + \frac{400}{400 + 400}} = 2.}$

The qualified composition with the smallest φ(λ) value is the optimal component composition. If two components are located on the same node (e.g., c₁ and c₂), then the residual bandwidth is set ∞ since the virtual link between two co-located components do not consume any network bandwidth.

Regarding step 4 (application session setup), the deputy node 202 finally establishes the stream processing application session by sending confirmation messages along the selected component composition. The confirmation message makes transient resource allocation permanent on the selected nodes and virtual links. If no qualified component composition can be found, then the deputy node 202 returns a failure message.

A description will now be given regarding hierarchical state management.

The hierarchical state management includes fine-grain local state update and coarse-grain global state maintenance. The local state of a node includes the QoS/resource states of its neighbor nodes in the overlay mesh, and its adjacent overlay links. Each node keeps its local state with high precision using frequent proactive measurement at short time intervals (e.g., 10 seconds, of course other time intervals may be used). For scalability, the precise local state is not disseminated to other nodes.

The global state includes: (1) the QoS and resource states of all nodes; and (2) the QoS and resource states of all virtual links between all pairs of nodes. Since each node can provide multiple stream processing components, the QoS states of each node includes the QoS states of all the stream processing components it provides. For scalability, the global state update is performed at a coarse-grain level. The global state update is triggered only when the QoS and resource state changes on a node or an overlay link exceeds a pre-specified (e.g., large) threshold. Thus, many insignificant state variations are filtered out to reduce the global state maintenance overhead. For example, a node updates its available memory state in the global state only when the available memory variation is larger than 100 KB or some other pre-specified amount. Similarly, a node updates the available bandwidth of its adjacent overlay link in the global state only when the available bandwidth variation is more than 200 kbps or some other pre-specified amount. It is to be appreciated that the preceding parameters are merely illustrative and, thus, other values may be used for available memory variation and available bandwidth variation, while maintaining the scope of the present invention.

One complication in the global state update is that each virtual link is an overlay path that includes several overlay links. Thus, the virtual link state update requires further aggregation from the states of its constituent overlay links. For example, it is desired to update the available bandwidth of a virtual link (l_(i)) in the global state, which is mapped to an overlay path l_(i)=

e₁, . . . , e_(k)

. Then, the available bandwidth of l_(i) is calculated from the available bandwidth of its constituent overlay links: ba^(l) ^(i) =min(ba^(e) ^(i) , . . . , ba^(e) ^(k) ). Similarly, the QoS values (e.g., delay, loss rate, and so forth) for the virtual link l_(i) are to be calculated before the state of the virtual link l_(i) can be updated in the global state. Thus, one node (e.g., the least loaded node) is selected as the aggregation node to calculate the states of all virtual links. All other nodes send significant QoS/resource state changes of their adjacent overlay links to the aggregation node. The aggregation node periodically updates the global state with the states of all virtual links between all pairs of nodes in the overlay mesh at pre-specified (e.g., large) time interval (e.g., 10 minutes or some other pre-specified time interval). For load sharing, the aggregation role is rotated among all the nodes (e.g., round-robin, least loaded first, and so forth).

The distributed hash table (DHT) system is used to store the global state for scalability and failure resilience. Thus, the global state storage load and query computation load can be distributed among all nodes. The global state hash table records the coarse-grain QoS/resource states of all nodes and virtual links in the form of

node identifier, coarse-grain QoS/resource states

and

link identifier, coarse-grain QoS/resource states

. If a node wants to acquire the coarse-grain QoS/resource states about a specific node or a virtual link, then the node can query the global state hash table using the node identifier or link identifier. The DHT system can evenly partition the global state hash table and distribute hash table entries among all nodes.

A description will now be given regarding adaptive probe number selection.

The approach for deciding the number of probes used for each request will now be described. The concept of probing ratio will now be defined. If a function F_(i) has k_(i) candidate components and the probing ratio is α, then ACP will use ┌α·k_(i)┐ probes to examine ┌α·k_(i)┐ candidate components for the function F_(i). Intuitively, the larger the probing ratio is, the better composition performance the ACP can achieve since more candidate compositions are examined. However, larger probing ratio also means larger probing overhead since more probes are generated. Thus, the probing ratio represents a tuning knob to control the trade-off between composition performance and probing overhead. Composition success rate μ(t) is used to characterize the composition performance of the system at sampling time (t). The composition success rate is calculated as follows:

${{\mu\;(t)} = \frac{{SuccesNum}(t)}{{RequestNum}(t)}},$ where SuccessNum(t) denotes the number of successful compositions during last sampling period [t−Δt,t] and RequestNum(t) denotes the number of total composition requests during [t−Δt,t]. A higher composition success rate μ(t) indicates better optimal component composition performance at time t. The probing ratio value at time t is denoted by α(t).

Ideally, ACP should always use the minimal probing ratio α(t) for achieving a target composition success rate μ(t) under different system conditions (e.g., workload, QoS/resource requirements). For example, FIGS. 5A and 5B are plots 510 and 550 illustrating composition performance (i.e., success rate) as a function of probing ratio under increasing workload and higher QoS requirements. The number of requests submitted per minute is denoted using the request rate. A higher request rate represents larger workload. For example, in FIG. 5A, if it desired to achieve μ(t)=95% composition success rate when the request rate is 50 requests per minute, then the ACP should set the probing ratio α(t)=0.3. However, the challenge of probing ratio tuning is that the mapping from probing ratio to success rate is non-linear and dynamic. The mapping function can be affected by different system conditions (e.g., request rate, QoS/resource requirements) in a dynamic distributed stream processing system. For example, FIG. 5A illustrates the mapping functions from probing ratio to composition success rate under different request rates. FIG. 5B illustrates the composition success rate as a function of the probing ratio under different QoS requirements. Higher QoS means shorter processing time and lower loss rate requirements.

To address the problem, ACP performs on-line profiling to dynamically derive the current mapping function from probing ratio to composition success rate. Based on the profiling results, ACP can predict the minimal probing ratio α(t) given a target success rate μ(t). It is presumed that the target success rate is achievable. ACP stops increasing the probing ratio if the probing overhead already reaches its limit. The on-line profiling is triggered when the prediction error exceeds a certain threshold δ (e.g., δ=2%), which means that the system conditions have changed. For example, if the target success rate is μ(t), then ACP predicts the minimal probing ratio α(t) based on the current profiling results. At the end of this sampling period, ACP gets the measured success rate μ(t). If |μ(t)−μ(t)|>δ, then profiling is triggered to derive the new mapping function from the probing ratio to the composition success rate.

Since ACP is highly efficient, the success rate increases very quickly and reaches the saturation value (i.e., the highest achievable success rate) at a small probing ratio, illustrated by FIGS. 5A and 5B. Thus, the probing ratio tuning space is very limited, which makes probing ratio profiling a simple task. The profiling process starts from the base probing ratio (e.g., α=0.1) and gradually increases the probing ratio at a certain step (e.g., 0.1) until the success rate hits the saturation value. To guarantee high prediction accuracy, profiling should use a realistic workload that is representative of the current system conditions (e.g., request rate, QoS requirements, resource requirements, application templates, and so forth). Such a workload can be the trace replay of actual workloads in the last sampling period.

A description will now be given regarding per-hop component selection.

After the deputy node decides the probing ratio, the deputy node executes the ACP protocol to send out composition probes. When a node v_(i) receives a probe, the node v_(i) needs to decide which next-hop candidate components to examine under the probing ratio constraint. For example, if the next-hop function F_(i) has k_(i) candidate components and the probing ratio is α, then the node v_(i) is allowed to probe ┌α·k_(i)┐ candidate components for F_(i). Under the guidance of the coarse-grain global state, v_(i) selects the M best candidate components as described in the following three steps.

In the first step, v_(i) queries the global state to retrieve the coarse-grain QoS/resource states of all candidate components c₁, . . . , c_(k) and virtual links l₁, . . . , l_(k) to the candidate components. The QoS states of the candidate component c_(i) and the virtual link l_(i) are described by [q₁ ^(c) ^(l) , . . . , q_(m) ^(c) ^(i) ] and └q₁ ^(l) ^(i) , . . . , q_(m) ^(l) ^(i) ┘, respectively. The resource states of the candidate component c_(i) include current resource availabilities [ra₁ ^(c) ^(i) , . . . , ra_(n) ^(c) ^(i) ]. The resource states of the virtual link l_(i) include its current available bandwidth ba^(l) ^(i) . On the other hand, v_(i) acquires the resource/QoS requirement information from the received probe. The end-system resource requirements of the application are denoted using └r₁ ^(c) ^(i) , . . . r_(n) ^(c) ^(i) ┘, and the bandwidth requirement of the user is denoted using b^(l) ^(i) . The residual resources of c_(i) are calculated as rr_(i) ^(c) ^(i) =ra_(i) ^(c) ^(i) −r_(i) ^(c) ^(i) , and the residual bandwidth of l_(i) is calculated as rb^(b) ^(i) =ba^(l) ^(i) −b^(l) ^(i) .

In the second step, v_(i) filters out unqualified candidate components by checking the input/output stream rate compatibility between the current-hop component and candidate next-hop components. Then, v_(i) further removes unqualified candidate components according to the QoS/resource requirements of the user and the state information retrieved from the global state. The user's QoS requirements for the composed stream processing application are denoted using └q₁ ^(req), . . . , q_(m) ^(req)┘. It is presumed that the accumulated QoS values of the probed partial component composition are q₁ ^(λ), . . . , q_(m) ^(λ). A candidate component c_(i) is unqualified if any of the following inequalities is true: q _(i) ^(λ) +q _(i) ^(c) ^(i) +q _(i) ^(l) ^(i) >q _(i) ^(req) ,∃i,1≦i≦m  (6) ra _(i) ^(c) ^(i) <r _(i) ^(c) ^(i) ,∃i,1≦i≦n  (7) ba^(l) ^(i<b) ^(l) ^(i)   (8)

Equation 6 means that the user's QoS constraints cannot be satisfied. Equation 7 means that the candidate component c_(i) cannot meet the end-system resource requirements. Equation 8 means the virtual link to c_(i) cannot meet the bandwidth requirement.

In the third step, v_(i) further selects good candidate components from the above derived qualified components. It is presumed that v_(i) finds Z qualified candidate components. If Z≦M, then v_(i) can probe all the qualified candidate components satisfying the probing ratio constraint. Otherwise, v_(i) needs to select M best qualified components from Z qualified ones. The virtual link from the current component to c_(i) is denoted using l_(i). To meet the multi-constrained QoS requirements └q₁ ^(req), . . . , q_(m) ^(req)┘, a risk function D(c_(i)) is defined for a candidate component c_(i) as follows:

$\begin{matrix} {{D\left( c_{i} \right)} = {\max\left( {\frac{q_{1}^{\lambda} + q_{1}^{c_{i}} + q_{1}^{l_{i}}}{q_{1}^{req}},\ldots\mspace{11mu},\frac{q_{m}^{\lambda} + q_{m}^{c_{i}} + q_{m}^{l_{i}}}{q_{m}^{req}}} \right)}} & (9) \end{matrix}$ The larger the ratio value

$\frac{q_{i}^{\lambda} + q_{i}^{c_{i}} + q_{i}^{l_{i}}}{q_{i}^{req}}$ is, the more closely the QoS accumulation (q_(i) ^(λ)+q_(i) ^(c) ^(i) +q_(i) ^(l) ^(i) ) approaches its constraint q_(i) ^(req). The candidate components with smaller risk function values are considered as better components since their maximum QoS violation risk values are smaller. Thus, c_(i) is a better candidate component to probe than c_(j) if D(c_(i))<D(c_(j)). If two candidate components have similar risk function values, the two candidate components are compared based on the load distribution goal. A congestion function W (c_(i)) is defined as follows:

$\begin{matrix} {{W\left( c_{i} \right)} = {{\sum\limits_{k = 1}^{n}\frac{r_{k}^{c}}{{rr}_{k}^{c_{i}} + r_{k}^{c_{i}}}} + \frac{b^{l_{i}}}{{rb}^{l_{i}} + b^{l_{i}}}}} & (10) \end{matrix}$

The component with smaller W (c_(i)) values is a better candidate to probe since it is less loaded. The candidate component selection approach described above essentially ensures that probes traverse along “good” candidate compositions. The fine-grain QoS/resource states collected by the probes will be used to select the best component composition. Thus, ACP can most efficiently find the optimal component composition although ACP only examines a subset of all candidate compositions.

These and other features and advantages of the invention may be readily ascertained by one of ordinary skill in the pertinent art based oh the teachings herein. It is to be understood that the teachings of the invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or combinations thereof.

Most preferably, the teachings of the present invention are implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPU”), a random access memory (“RAM”), and input/output (“I/O”) interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit.

It is to be further understood that, because some of the constituent system components and methods depicted in the accompanying drawings are preferably implemented in software, the actual connections between the system components or the process function blocks may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the pertinent art will be able to contemplate these and similar implementations or configurations of the present invention.

Although the illustrative embodiments have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications may be effected therein by one of ordinary skill in the pertinent art without departing from the scope or spirit of the invention. All such changes and modifications are intended to be included within the scope of the invention as set forth in the appended claims. 

1. A method for optimizing component composition in a distributed stream-processing environment having a plurality of nodes capable of being associated with one or more of a plurality of stream processing components, the method comprising the steps of: performing an adaptive composition probing (ACP) which probes a subset of the plurality of stream processing components to determine the optimal component composition in response to a stream processing request; and managing local and global information for use by said performing step in determining the optimal component composition, wherein said performing step adaptively determines the number of probes used for the stream processing request based on at least one of system performance targets and current system conditions, and wherein said performing step adaptively performs per-hop component selection based on at least one of coarse-grain global state information, accumulated probing results, and stream rate matching. 